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Description 

METHOD AND SYSTEM FOR 
FACILITATING ACCESS TO EXTERNAL 

DATA 

Field of Invention 

[0001] This application generally discloses a method of accessing 
information and, more particularly, a computer-imple- 
mented system and method for facilitating the access and 
exchange of information among otherwise incompatible 

computing systems. 
Background of Invention 

[0002] Computer software has typically been operable only on 
the specific computing platform for which the software 
was created. For example, software developed for use on 
the Linux® operating system is typically not operable on 
computers running the Microsoft Windows® operating 
system. Similarly, the data stored by the various programs 
may not be stored on systems run by different operating 



systems. Thus, in order to share programs and data 
among various incompatible platforms, the programs and 
data were first converted to be operable on all the desired 
platforms. 

[0003] | n the past, different data has been stored and maintained 
on various different computing platforms. For example, 
certain entities use systems based on Microsoft technol- 
ogy, such as, for example, Windows NT, Internet Informa- 
tion Services ("IIS"), and Component Object Model ("COM"). 
Other entities may use systems based on a UNIX platform, 
such as those developed by Sun Microsystems, using pro- 
grams such as, for example, WebSphere Application 
Server ("WAS") and programming languages such as JAVA. 
In certain situations, a single organization may use two or 
more different platforms. In other situations, one organi- 
zation may wish to share data or programs with another 
organization which uses a different computing platform. 

[0004] with the recent proliferation of the use of the Internet and 
the growth in connectivity between computers, it has be- 
come more desirable to share data and programs among 
various distributed locations. Of particular interest is the 
ability to access various pieces of information, even when 
the data and programs containing the information were 



created for incompatible platforms. In the past, tools were 
used to convert programs such that they are operable on 
other platforms. However, such tools tended to be cum- 
bersome, expensive, and wasteful in the use of computing 
resources. Therefore, there is a need for an efficient tool 
that allows for the use of various programs and data 

across multiple platforms. 
Summary of Invention 

[0005] | n general, the present invention uses a transaction in- 
frastructure (e.g., .NET component, JavaBeans, Java Enter- 
prise Edition, etc.) to provide access to external data. The 
access to the external data is provided via an interface 
that takes a request object and returns a response object. 
The objects include "application syntax," and make the 
underlying protocol/data formats invisible to the user of a 
system of the present invention. 

[0006] More particularly, the system provides application access 
to external data by using a data component that translates 
requests for data into .NET objects. The .NET objects are 
used to retrieve information from a variety of different 
data sources that contain data stored in a number of dif- 
ferent formats. The data component retrieves the data 
from the data sources and creates a response .NET object 



that can be transmitted to a requestor. The manner in 
which a data component accesses data may be defined by 
a Data Service Transaction ("DST"). A DST may comprise 
two different files: an XML file defining the attributes of 
the transaction; and a Dynamic Link Library ("DLL") gener- 
ated from the XML file that defines the input and output 
objects to be passed to and from the data component 
when accessing the transaction. 

[0007] jo retrieve data from a new data source, it is only neces- 
sary to create a new DST. In such a manner, a requestor 
can retrieve data without the need to translate data into a 
particular format. In this embodiment, the .NET object 
may be available via a web service, thereby allowing ac- 
cess via a variety of different computing tools such as, for 
example, a personal computer, a telephone, and a PDA. 

[0008] a DST is created by first defining the interface to be used. 
The DST is then automatically created and stored in a lo- 
cation accessible by the data component. When a request 
is sent to the data component in the form of a .NET ob- 
ject, the data component retrieves the DST associated with 
the request. The data component then creates a dynamic 
key to determine if the request has already been pro- 
cessed. The data component determines if a transforma- 



tion of data is required. If not, the request is sent as an 

XML stream. If transformation is required, the request is 

translated into the appropriate format. The message is 

then sent to the data source. 

[0009] jo retrieve information, the DST is retrieved to determine 

the status of the request. If the request is complete, the 

data is obtained in an XML format and passed to a service 

provider component. The result of the request is obtained, 

then transformed into XML. The XML data is returned to 

the data component, which converts the XML into a .NET 

object and sends the object to the requesting component. 
Brief Description of Drawings 

[0010] a more complete understanding of the present invention 
may be derived by referring to the detailed description 
and claims when considered in connection with the Fig- 
ures, where like reference numbers refer to similar ele- 
ments throughout the Figures, and: 

[0011] Figure 1 presents a block diagram system overview of an 
embodiment of the present invention; 

[0012] Figure 2 presents a flow chart illustrating exemplary steps 
in creating a DST; 

[0013] Figure 3 presents a flow chart illustrating exemplary steps 
in creating a PutMessage; and 



[0014] Figure 4 presents a flow chart illustrating exemplary steps 

in creating a GetMessage. 
Detailed Description 

[0015] The present invention may be described herein in terms of 
various functional components and various processing 
steps. It should be appreciated that such functional com- 
ponents may be realized by a variety of different hardware 
or structural components configured to perform the spec- 
ified functions. For purposes of illustration only, exem- 
plary embodiments of the present invention will be de- 
scribed herein. Further, it should be noted that, while var- 
ious components may be suitably coupled or connected to 
other components, such connections and couplings may 
be realized by a direct connection between components, 
or by a connection through other components and de- 
vices. 

[0016] For the sake of brevity, conventional data networking, ap- 
plication development and other functional aspects of the 
systems (and components of the individual operating 
components of the systems) may not be described in de- 
tail herein. Furthermore, the connecting lines shown in the 
various figures contained herein are intended to represent 
exemplary functional relationships and/or physical cou- 



plings between the various elements. It should be noted 
that many alternative or additional functional relationships 
or physical connections may be present in a practical sys- 
tem of the present invention. 

[0017] a system of the present invention may include a host 

server or other computing systems including a processor 
for processing digital data, memory coupled to said pro- 
cessor for storing digital data, an input digitizer coupled 
to the processor for inputting digital data, an application 
program stored in said memory and accessible by said 
processor for directing processing of digital data by said 
processor, a display coupled to the processor and memory 
for displaying information derived from digital data pro- 
cessed by said processor, and a plurality of databases, 
said databases including client data, seller data, supplier 
data and/or like data that could be used in association 
with the present invention. As those skilled in the art will 
appreciate, a computer will typically include an operating 
system (e.g., Windows NT, 95/98/2000, Linux, Solaris, 
etc.) as well as various conventional support software and 
drivers typically associated with computers. 

[0018] The applications discussed herein may be associated with 
databases. The term "database", "data sources" or similar 



terms may refer to any type of data organizing mecha- 
nism, such as relational databases, hierarchical databases, 
object-oriented databases, spreadsheets, and/or the like. 
Common database products that may be used to imple- 
ment the databases include DB2 by IBM (Armonk, NY), any 
of the database products available from Oracle Corpora- 
tion (Redwood Shores, CA), Microsoft Access, Microsoft 
Excel, or SQL Server by Microsoft Corporation (Redmond, 
Washington), or any other database product. Databases 
may be organized in any suitable manner, including as 
data tables or lookup tables. Association of certain data 
may be accomplished through any data association tech- 
nique known and practiced in the art. For example, the 
association may be accomplished either manually or auto- 
matically. Automatic association techniques may include, 
for example, a database search, a database merge, GREP, 
AGREP, SQL, and/or the like. The association step may be 
accomplished by a database merge function. A "key field" 
partitions the database according to the high-level class 
of objects defined by the key field. For example, a certain 
class may be designated as a key field in both the first 
data table and the second data table, and the two data ta- 
bles may then be merged on the basis of the class data in 



the key field. In this embodiment, the data corresponding 
to the key field in each of the merged data tables is 
preferably the same. However, data tables having similar, 
though not identical, data in the key fields may also be 
merged by using AGREP, for example. It should also be 
understood that a system of the present invention is not 
limited to a physical implementation of a single repository 
of information. It is also possible to have multiple reposi- 
tories of information. The multiple repositories may be 
linked together in a variety of different manners to create 
a single logical repository of information. 
[0019] Communication between the parties to the transaction 
and the system of the present invention is accomplished 
through any suitable communication means, such as, for 
example, a telephone network, Intranet, Internet, point of 
interaction device (point of sale device, personal digital 
assistant, cellular phone, kiosk, etc.), online communica- 
tions, off-line communications, wireless communications, 
transponder communications and/or the like. One skilled 
in the art will also appreciate that, for security reasons, 
any databases, systems, or components of the present in- 
vention may consist of any combination of databases or 
components at a single location or at multiple locations, 



wherein each database or system includes any of various 
suitable security features, such as firewalls, access codes, 
encryption, decryption, compression, decompression, 
and/or the like. 

[0020] | n general, an embodiment of the present invention pro- 
vides a single interface (or reduced number of interfaces) 
for facilitating multiple components access to data. Such 
an interface is provided by, for example, creating a data 
access layer in a generic format, such that the data access 
layer can be accessed by a Microsoft .NET application or 
any transaction infrastructure or similar application. In 
such a manner, a variety of different programs and de- 
vices can access a single system, without needing to 
translate information from different formats. One skilled 
in the art will appreciate that, while certain embodiments 
may be disclosed in terms of the .NET application, the in- 
vention is not so limited and any application which per- 
forms functions similar to the Microsoft .NET application 
may be used in the present invention in place of, or in ad- 
dition to, the .NET object as used herein, such as, for ex- 
ample, a JAVA application (e.g., JavaBeans, Java Enterprise 
Edition). 

[0021] A n "object" used herein includes small program that per- 



forms a specific function (e.g., send a query to a database 
or send results of a query to another object or applica- 
tion). As such, programs can utilize the "services" of ob- 
jects without having to contain the code internally, thus 
saving development time, code redundancy and a theoret- 
ical increase in computing efficiency. A ".Net" object as 
used herein includes architecture configured to add 
portability to applications and also allows a program to be 
written in multiple languages and compiled as one. More 
specifically, Microsoft® .NET is a set of Microsoft software 
technologies for connecting information, people, systems, 
and devices. .NET facilitates the integration of software 
applications and data through the use of web services. 
The .NET framework may include two main parts, namely 
the common language runtime (CLR) and a unified, hierar- 
chical class library that includes a Active Server Pages 
(ASP.NET®), an environment for building smart client ap- 
plications (Windows Forms), and a data access subsystem 
(ADO.NET®). 

[0022] Figure 1 is a block diagram illustrating an exemplary in- 
teraction of an embodiment of the present invention with 
multiple systems. A variety of different apparatuses, such 
as PC 102, telephone 104, PC 106 and PDA 108, can ac- 



cess systems such as web pages 110 or web services 112 
(via a web server). Web services include discrete, building- 
block applications that connect to each other as well as to 
other, larger applications over a network. Web pages 110 
and web services 112 are used to access business compo- 
nents 120. By accessing business components 120 
through web pages 110 and web services 112, a user can 
perform a variety of different tasks, such as performing 
sales and marketing tasks, servicing accounts, and the 
like. Business components 120 may need to access data 
from a variety of different data sources, such as data 
sources 140, 142, 144, 146, and 148. Because data 
sources 140, 142, 144, 146, and 148 may be in a variety 
of different formats, it may not be possible for business 
components 120 to directly access the data. Business 
components 120 access data sources 140, 142, 144, 146, 
and 148 through data component 130. 
[0023] D a ta component 130 is configured to convert any portion 
or all data from data sources 140, 142, 144, 146, and 148 
into a .NET object. Thereafter, business component 120 is 
configured to retrieve the .NET object from data compo- 
nent 130. In addition, business components 120 can be 
configured to make requests for certain portions of data. 



Such requests are transmitted to data component 130 as 
.NET objects. Data component 130 can then access the 
requested data from one of data sources 140, 142, 144, 
146, and 148. 

[0024] The manner in which data component 130 accesses data 
may be defined by a Data Service Transaction ("DST"). A 
DST may comprise two different files: an XML file defining 
the attributes of the transaction; and a Dynamic Link Li- 
brary ("DLL") generated from the XML file that defines the 
input and output objects to be passed to and from data 
component 130 when accessing the transaction. The use- 
fulness of using a DST is readily apparent — a new data 
source can be accessed merely by creating a DST that de- 
fines how the new data source is organized. The organi- 
zation of the data source may be provided by the data 
provider of the data source. For example, for a mainframe 
COBOL program, the REQUEST CHAPTER and REPLY CHAP- 
TER layouts are provided. For a data source with an XML 
interface, a sample XML request stream and sample XML 
response stream is typically provided. For a DB2 database, 
the stored procedure name and interface may be pro- 
vided, along with a list of elements of any record sets re- 
turned. The stored procedure name, interface and list of 



record sets may also be used to automatically import and 
generate a DST. 

[0025] The XML schema used by the DST may be one of a variety 
of different formats. In one exemplary embodiment, the 
DST contains the following information: message type; In- 
put; Output; Hub Version; and Element. In one embodi- 
ment, for every transaction supported by data services, an 
XML transformation file is placed in a path referred to in 
the registry entry, such as, for example: 
HKEY_LOCAL_MACHINE\SOFTWARE\AmericanExpress\SDP 
\TransactionDirectory. Furthermore, XVIINFO01 may be a 
data service transaction, and for the application using 
data services to access the Processor Profile, the XVI- 
INFO01.XML transformation file resides in the directory 
specified at the above registry entry. 

[0026] As used herein, a DST file is an XML document which may 
follow the exemplary schema for the XML transformation 
files below. 



<?xml version-' 1.0" cncoding="utf-8"?> 

<xs: schema dementFormDdault="qualified'' 

xmlns:xs="http:/Avww.w3.org/2001/XMLSchema"> 

<vs-Rlftment.name= " Transaction " type="TransactionType" /> 

<xs:complexTypename="TransactionType"> 
<xs:sequence> 

<xs:element minOccurs- '0" maxOccurs="l" name="ProcessorProfile" 
type-'ProcessorProfileType" /> 

<xs:elcment minOccurs="0" maxOccnrs="l" nnme=" AuthorizationTransaction" 
type="AuthorizationTransacUonT>pc"/> 

<xs:element minOccurs="0" maxOccurs="l" name="RuleServicc" 
tvpe-'AumorizationTransactionType" l> 

' <xs:element minOccurs="0" niaxOccurs="l" name "l)l52Storedl'roccd!.ire" 

type- 'AuthorizationTransactionTypc" l> 

<xs:element minOccurs="0" maxOccurs=" 1 " name="lnput" type='TnputTvpe" /> 
<xs:element minOccurs="0" maxOccurs=" 1 " name="Ontput" type="OutputType" l> 

</xs:scquence> 

<xs:attributename="£D" type="xs: string" l> 
<xs:attribute name- 'Name" type="xs:string" /> 
<xs:attributc name^'Timeont" type="xs:long" l> 
<xs:attributc n:ime- "Cashable" type="xs:boolean" t> 
<xs.attribute name=''Rcseiidable'' type="xs.boolean" l> 
<xs:attributename="FEPi" type="xs:boolean" A> 
<xs:attribute iiame=" AinexIDReqmred " type="xs:boolean" t> 
<xs:attributename=''MessageTjpe 11 t>pe="xs:string" /> 
<xs:attribute name=" Description " t>pe="xs:string" /> 
<xs:attribute name- 'Update" type="xs:boolean" /> 
<xs:attribute name=" Persistent " type="xs:boolean" /> 
<xs:attribute namc-' HubVersion " type="xs:String" /> 
</xs : complexTyp e> 

<xs: complexType name="ProcessorProfileType"> 

<xs:attribute name="Name'' type="xs:string" l> 

<xs:attribute namc=" XMLTag " type="xs:string" /> 

<xs:attributc name=" HubEnablcd " type="xs:int" /> 

<xs:attribute name=" AmexIDRequir ed" typc="xs:boolean" l> 

<xs:attributeiuinic- 'TranjLfonn" typc="xs:boolean" f> 
</xs:complexType> 

<xs:coniplexTypename="AuthorizationTransactionT\pe"> 
<xs.attribute name=" Name " type="xs:string" /> 
</xs : complexTyp e> 

<xs:complexT.vpe name="DB2StorcdProcedureType"> 
<xs:atlribute name=" Name " type="xs:string" i> 
<xs:attribute nMTnK=" nSNRegistr\-Location " type="xs: string" f> 

</xs : complexTyp e> 

<xs : complexTyp e n ame="RuleServiceType"> 
<xs:attribute name=" RiileServcrConfigFile " type="xs:string" l> 
<xs:attribute name- ' RuIeServer " type="xs:string" /> 

</xs:complexType> 

<xs:complexType name="InputType"> 
<xs:sequence> 

<xs:element minOccurs="0" maxOccurs="unbounded" name= Element 
type="ElcmentType" /> 
</xs:sequence> 

<xs:attributename=''2MLTag'' type="xs:string" /> 

<xs:attribute name="Length" type="xs:int" /> . 



</xs: complexType> 

<xs:complcxTjpe name="ElementT3pe"> 

<xs:sequence> 

<xs:element minOccurs="0" maxOccurs="unbounded" name="Element" 
type="ElemenfType" t> 
</xs:sequence> 

<xs:attribute name-' Length " t)pe="xs:long" !> 
<xs:attribute name- ' Offset " type="xs:long" l> 
<xs:attribute name=" XMLTag " type="xs:string" /> 
<xs:attribute name- ' Name " typc="xs: string" /> 
<xs:attribute name-'Kcv" type="xs:boolean" l> 
<xs: attribute name- ' MaxRepeats " lype="xs:long" /> 
<xs:attribute name-'R epeatsOffset " type="xs:long" t> 
<xs ; attribute name-' Rep eatsLen gth " type="xs:int" l> 
<xs:attribute namc=" DataTvpe " type="xs:int" /> 
<xs: attribute name- ' Attribute " type="xs:boolean" /> 
<xs:attribute name=" Direction " t>pe="xs:inl" /> 
</xs : corap lexTyp e> 

<xs:complexType name="OutpufType"> 

<xs:sequeuce> 

<xs:element minOccurs="0" maxOccurs="unbounded" name=" Elcmcnt " 
type="ElementTvpe" /> 
</xs:sequence> 

<xs:attribute name=" XMLTag " rypc="xs:string" /> 
</xs : complexTyp e> 
</xs:schema> 



[0027] A n exemplary definition of each element in this schema is 
set forth below. The transaction includes the root element 
of the XML transformation file and it may contain three 



child elements including input, output and data provider. 
The data provider may include a AuthorizationTransaction 
element, an ProcessorProfile element, a RuleService ele- 
ment, and a DB2StoredProcedure element. The invention 
also contemplates that more elements are possible as 
more data providers are added to data services. The 
transaction may also include certain attributes, such as, 
for example, name, ID, timeout, cachable, resendable, 
FEPI (front end programming interface), AMEXIDRequired, 
MessageType, Description, Persistent, HubVersion and 
Update. 

[0028] The input describes the input desired to access the trans- 
action. The content of this schema element describes, if 
transformation is to be done, how to convert the XML 
passed to data services to the format expected by the 
data provider. The input may consist of none to many ele- 
ments, and may include length and XMLTag attributes. 
The output describes the output returned from the trans- 
action. The content of this schema element describes, if 
transformation is to be done, how to convert from the 
format returned by the data provider to the XML passed 
from data services. The output can consist of none to 
many elements, and may include the XMLTag attribute. 



[0029] AuthorizationTransaction describes attributes specific to 
an authorization system such as Name and may only be 
present in an XML Transformation File if the Message Type 
is "Authorization". ProcessorProfile describes attributes 
specific to a message processor such as, for example, 
Name, XMLTag, HubEnabled, AmexIDRequired and Trans- 
form. ProcessorProfile may only be present in an XML 
Transformation File if the Message Type is "Processor". 
DB2StoredProcedure describes attributes specific to a DB2 
Stored Procedure such as, for example, name and 
DNSRegistryLocation. DB2StoredProcedure may only 
present in an XML Transformation File if the Message Type 
is "DB2". RuleService describes attributes specific to a Rule 
Service such as, for example, RuleServerConfigFile and 
RuleServer. RuleService may only be present in an XML 
Transformation File if the Message Type is "RULSVC". 
Name describes Transaction Name. ID describes a trans- 
action identifier which may be the same as the transaction 
name, but in other embodiments, it may be different. For 
example, for AuthorizationTransactions this is different, 
as the transaction ID on the hub is different than the 
transaction name used on the server. This ID is used to 
identify to the data provider (e.g., Authorization, Proces- 



sor) the transaction being requested. Timeout describes 
the Default Transaction Timeout which is the maximum 
amount of time for the transaction. When calling DataSer- 
vices.GetMessage, a timeout exception may be reported 
after this number of milliseconds has elapsed since the 
request was made which may be a default for the transac- 
tion. Application code, when calling data services, can 
specify a different timeout value. 
[0030] Cachable indicates if cached data, when present, can be 
used for the transaction. In general, update transactions 
are not cachable which may be a default for the transac- 
tion. Application code, when calling data services, may re- 
quest that data not be obtained from cache even if 
marked as cachable. Resendable may indicate if the trans- 
action can be re-sent. FEPI (front end programming inter- 
face) indicates if the transaction uses a FEPI screen(s) and 
the system may use this information to determine if it is 
not safe to send a FEPI transaction because another FEPI 
transaction is still being processed. AmexIDRequired indi- 
cates if a transaction requires the user's ID and the system 
may use this information to determine whether to try to 
fetch the ID (from cache or XVAMXID02) prior to sending 
request to the servicing component. 



[0031] MessageType is a type of transaction with the following 
exemplary values. If the transaction is a processor profile 
and if the value is Processor, the ProcessorProfile element 
must be present. If the transaction is a Authorization 
transaction and if the value is Authorization, the Autho- 
rizationTransaction element must be present. If the trans- 
action is a DB2 stored procedure and if the value is DB2, 
the DB2StoredProcedure element must be present. If 
transaction is a Rule Service and if the value is RULSVC, 
the RuleService element must be present. The MQXML is 
present if the transaction is a Hub service sending XML to 
the hub. As the system expands to connect to more data 
providers, the values may expand. 

[0032] Persistent applies to transactions that use MQ for its com- 
munication protocol. If true, the message placed on the 
queue should be persistent, so that if something is down, 
the message is guaranteed to be delivered at a later time. 
This also causes the message to never expire, so if 
needed, the message will remain on the queue indefi- 
nitely, until it is removed from the queue. If false (default 
for SDP), the message expires according the Expiry reg- 
istry entry, and is not persistent when placed on the PUT 
queue. HubVersion is the version of the hub header(s) to 



be used if the transaction uses the hub for transport. The 
version numbers include the following instructions: 0 Hub 
is not used; 1 RFH1 header is used for Hub communica- 
tions when invoking this service; 2 RFH2 header is used 
for Hub communications when invoking this service; 3 EMI 
Envelope Version 0 is used for Hub communications when 
invoking this service; and, 4 - EMI Envelope Version 1 is 
used for Hub communications when invoking this service. 
Update indicates if the transaction is an Update transac- 
tion. If a stored procedure is marked as an update trans- 
action (i.e., this attribute is True), then an entry is added 
to the audit log every time the stored procedure is called. 
Otherwise, no audit entry is made. Description includes a 
brief description of the transaction. 
[0033] The ProcessorProfile Schema Element Attributes include, 
for example, Name, XMLTag, HubEnabled, Amex- 
IDRequired and Transform. Name refers to the name of 
Processor Profile which is sent in the Processor header to 
identify the profile. XML Tag may be used when sending 
Processor request in XML format to the hub. HubEnabled 
indicates whether the Processor profile should be ac- 
cessed via the HUB wherein the codes may include, for ex- 
ample: 0 Should use point-to-point connection to Proces- 



sor to access the Processor Profile; 1- Profile is available 
via the hub, and should be accessed through the hub us- 
ing hub transformation (i.e., MRM data) and 2 - Profile is 
available via the hub, and should be accessed through the 
hub, not using hub transformation [i.e., BLOB data]. 
AmexlD may be similar to the Transaction attribute and it 
may instruct ProcessorServices whether to put the user's 
ID in Processor header when sending request to Proces- 
sor. Transform instructs ProcessorServices whether XML 
Request sent to data services should be transformed to 
copybook format prior to sending the request to Proces- 
sor, and response should be transformed from copybook 
format to XML after receiving response. This attribute may 
only apply if HubEnabled is 1 or 2. 
[0034] The AuthorizationTransaction Schema Element Attributes 
may include Name and Transform. Name may include the 
name of the Authorization Transaction which may be sent 
in the TPF header sent to the authorization system. Trans- 
form may instruct AuthorizationServices whether XML Re- 
quest sent to data services should be transformed to 
copybook format prior to sending the request to the au- 
thorization system, and response should be transformed 
from copybook format to XML after receiving response. 



[0035] The DB2 Stored Procedure Schema Element Attributes may 
include Name and RegistryLocation. The Name may be the 
name of DB2 Stored procedure to call, but it may or may 
not be the same as the transaction name. The DSNReg- 
istryLocation may include the name of registry value that 
contains the connection string for the database where the 
stored procedure resides. All such registry entries may be 
in the registry key for DB2 and the value specifies the reg- 
istry value within the registry key for DB2. 

[0036] The RuleService Schema Element Attributes may include 
RuleServerConfigFile and RuleServer. RuleServerConfigFile 
may include the full path to the Rule Server Configuration 
File to be used for this Rule Service. RuleServer may in- 
clude the name of the Rule Server for the rule service. 

[0037] The Input Attributes and Elements may include XMLTag, 
Length and Element. XML Tag may be used in an XML 
document passed to data services to mark the root of the 
input elements. The Length may include the total length 
of the input buffer to be sent to the provider and it may 
be applicable to fixed length formats. The Element may 
include an input which may contain none to many ele- 
ments and the Input elements may not utilize the ele- 
ment's Repeats Offset and Repeats Length attributes. 



[0038] The Output Schema Element Attributes may include XML- 
Tag and Element. XML Tag may be used in an XML docu- 
ment passed from data services to mark the root of the 
output elements. The Element may include an output 
which contains none to many elements and Input ele- 
ments which may not utilize the element's Key attribute. 

[0039] Access to the data sources 140, 142, 144, 146, and 148 
may be accomplished using a "factory pattern" that dele- 
gates the work to sub-components that are configured to 
access data sources 140, 142, 144, 146, and 148. There- 
fore, if a new data source is added, only a new sub- 
component may be needed to access the new data source. 
Thereafter, a DST is created that allows data component 
130 to interface with the new data source. 

[0040] a "factory pattern" is a software design pattern used in 

the design of the data services, wherein the factory design 
pattern specifies a factory which clients may use to access 
"products" provided by the factory. The factory/data ser- 
vices may be the single interface isolating the application 
from the multiple components being used internally to 
access the external data. In certain embodiments, data 
services may use a variant of the design pattern which 
may not return the factory "product" to the client; rather, 



data services may use the product internally to access the 
requested data. The pattern may use a specialized object 
solely to create other objects. 
[0041] Different variations of the factory pattern may be used 
with the present invention, although most variants typi- 
cally use the same set of primary actors, a client, a fac- 
tory, and a product. The client is an object that includes 
an instance of another object (the product) for some pur- 
pose. Rather than creating the product instance directly, 
the client may delegate this responsibility to the factory. 
Once invoked, the factory may create a new instance of 
the product, passing it back to the client. For a additional 
information related to the well known "factory pattern", 
see: 

http://msdn.microsoft.com/library/default.asp7url = /libra 
ry/en-us/dnbda/html/factopattern.asp, which is hereby 
incorporated by reference. 
[0042] | n certain embodiments, a new data source may be added 
when access to a new data source is desired using a com- 
munication protocol not yet supported by the data ser- 
vices. For example, a new sub-component may be added 
to access external web services. The sub-component may 
implement one or two methods, namely a PutMessage and 



a GetMessage if the communication protocol to the data 
source is inherently asynchronous (e.g., MQ), or Invoke, if 
the communication protocol to the data source is inher- 
ently synchronous (e.g., HTTP). In certain embodiments, a 
new sub-component may be added and derived from an 
existing sub-component due to some specific require- 
ments for the data source. For example, MQXMLServices is 
a sub-component derived from MQServices, because it 
adds a header to every message that is sent to the data 
source (i.e., hub). A data source may consist of a variety of 
different components, including a service provider com- 
ponent and a data source. The operation of the service 
provider component and the data source will be discussed 
in further detail below. 
[0043] Figure 2 includes a flowchart that illustrates the creation 

of a DST for a data source in an exemplary embodiment of 
the present invention. First, an interface to a data source 
is defined (step 202). The interface definition (204) is then 
used to create a DST (step 206). In one embodiment, a 
Windows application is used to create the DST. The data 
services dictionary GUI may provide an interface to view a 
list of data services transactions; view or modify the data 
service transaction definition; create a new data service 



transaction; import elements from a copybook layout or a 
DB2 stored procedure; generate input and output schemas 
for XML to/from data services to possibly hand off to the 
DAS (Data Architecture Services) for standardization; gen- 
erate request and response classes / assemblies; and, 
compare/merge two versions of a transaction definition. 

[0044] | n one embodiment, the GUI creates the XML structure for 
the DST from the imported data (e.g., copybook, XML, el- 
ement list). The DST is then used to build two XML 
schemas, namely, a request schema for the request ob- 
ject, and response schema for the response object (step 
212). A Microsoft .Net utility (XSD.exe) is used to build 
class files from these schemas, wherein the class files are 
compiled into DLLs which are deployed to the configured 
servers are typically stored in a database within data com- 
ponent 130 (step 216). The DLLs may be deployed to the 
portion of the configured servers where the data services 
component is running. Thereafter, data component 130 is 
able to use the DST and request and response objects to 
retrieve data from the data source. 

[0045] Figure 3 is a flowchart illustrating the operation of an ex- 
emplary embodiment of the present invention when ex- 
porting data to a data source (e.g., a PutMessage). DST 



files are stored in the file system. For performance rea- 
sons, as the DST files are used, they may be stored in 
shared memory so that a file does not need to be loaded 
every time a DST is used. In that regard, a request is con- 
verted into a .NET request object and the DST file may 
have been retrieved as a .NET request object from the 
calling component, (step 302). A dynamic key is then built 
for the requested transaction to determine if the request 
has already been made (step 304) to minimize multiple 
requests for the same data. A DST specifies the elements 
that may be "key" elements that uniquely identify the re- 
quest. As such, a key is built using the DST name con- 
catenated with the value of each key element. 
[0046] The request is then passed to the appropriate service 

provider component (step 306). For example, certain re- 
quests could be serviced by SQL Server, while other re- 
quests are serviced by MQXML, depending on the native 
format of the data. The service provider component deter- 
mines whether a message transformation is needed (step 
308). If the message format is XML, a .NET serialization 
converts the requested object to an XML stream (step 
310). Otherwise, a Message Transformation component is 
used to translate the message to the correct format (step 



312). The format may be determined by the MessageType 
element in the DST file. This element defines the data 
source, and thus, it defines the sub-component to use to 
access the data. The sub-component includes information 
related to the data format the data source desires of the 
data. The request is then sent to the data source for pro- 
cessing (step 314). The message ID may also be provided 
to the requesting application. The message ID may be de- 
sired so that the client can retrieve the responses by 
specifying the Message ID in the GetMessage. 
[0047] a GetMessage operation to retrieve data from a data 

source is performed as illustrated in Figure 4. Data com- 
ponent 130 looks up the DST for the requested service 
(step 402) and the status of the request is determined 
(step 404). The status may be determined in a variety of 
different manners such as, for example, when a request is 
made, an entry may be made in a database, including a 
message id. The entry is updated when the request is 
completed. The status of the request may be determined 
by retrieving the record of the request from the database. 
Such a request can be made in a variety of different man- 
ners, such as an SQL SELECT statement. If the data is 
available in SQL format, the data is obtained in XML for- 



mat (step 406). If the protocol of the data is MQ, the data 
is passed to the appropriate service provider component 
(step 408). The service provider component obtains the 
result of the request from the external data source (step 
410). If a transformation is required (as indicated by the 
DST), a Message Transformation component is used to 
transform the native format to XML (step 412). The result- 
ing XML is returned to data component 130 (step 414). 
The XML is de-serialized and translated into a .NET re- 
sponse object, which is then returned to the requesting 
application (step 416). 

[0048] | n one embodiment, the above-described method is used 
in asynchronous communication, in which obtaining data 
requires two steps, a request and a reply. In another em- 
bodiment, synchronous communication is used when the 
request can be satisfied upon being received by the data 
source. In such a situation, the steps taken are similar. 
However, after the data is sent to the data source for pro- 
cessing (step 314), the next step will be to determine if a 
transformation is required (step 412). From there, similar 
steps to those illustrated in Figure 4 are followed. 

[0049] The present invention is described herein with reference 
to block diagrams, flowchart illustrations of methods, 



systems, and computer program products according to 
various aspects of the invention. It will be understood that 
each functional block of the block diagrams and the 
flowchart illustrations, and combinations of functional 
blocks in block diagrams and flowchart illustrations, re- 
spectively, may be implemented by computer program in- 
structions. These computer program instructions may be 
loaded on a general purpose computer, special purpose 
computer, or other programmable data processing appa- 
ratus to produce a machine, such that the instructions 
which execute on the computer or other programmable 
data processing apparatus create means for implementing 
the functions specified in the flowchart block or blocks. 
[0050] it W i|| be appreciated that many applications of the 

present invention could be formulated. One skilled in the 
art will appreciate that the network may include any sys- 
tem for exchanging data or transacting business, such as 
the Internet, an intranet, an extranet, WAN, LAN, satellite 
communications, and/or the like. It is noted that the net- 
work may be implemented as other types of networks, 
such as an interactive television (ITV) network. The users 
may interact with the system via any input device such as 
a keyboard, mouse, kiosk, personal digital assistant, 



handheld computer (e.g., Palm Pilot®), cellular phone and/ 
or the like. Similarly, the invention could be used in con- 
junction with any type of personal computer, network 
computer, workstation, minicomputer, mainframe, or the 
like running any operating system such as any version of 
Windows, Windows NT, Windows 2000, Windows 98, Win- 
dows 95, Mac OS, OS/2, BeOS, Linux, UNIX, Solaris or the 
like. Moreover, although the invention is frequently de- 
scribed herein as being implemented with TCP/IP commu- 
nications protocols, it will be readily understood that the 
invention could also be implemented using IPX, Appletalk, 
IP-6, NetBIOS, OSI or any number of existing or future 
protocols. Moreover, the system contemplates the use, 
sale or distribution of any goods, services or information 
over any network having similar functionality described 
herein. 

[0051] The computing units may be connected with each other 
via a data communication network. The network may be a 
public network and assumed to be insecure and open to 
eavesdroppers. In the illustrated implementation, the net- 
work may be embodied as the internet. In this context, 
the computers may or may not be connected to the inter- 
net at all times. For instance, the customer computer may 



employ a modem to occasionally connect to the internet, 
whereas the bank computing center might maintain a per- 
manent connection to the internet. Specific information 
related to the protocols, standards, and application soft- 
ware utilized in connection with the Internet may not be 
discussed herein. For further information regarding such 
details, see, for example, Dilip Naik, "Internet Standards 
and Protocols" (1998); "Java 2 Complete", various authors, 
(Sybex 1999); Deborah Ray and Eric Ray, "Mastering HTML 
4.0" (1997). Loshin, "TCP/IP Clearly Explained" (1997). All 
of these texts are hereby incorporated by reference. 
[0052] These computer program instructions may also be stored 
in a computer-readable memory that can direct a com- 
puter or other programmable data processing apparatus 
to function in a particular manner, such that the instruc- 
tions stored in the computer-readable memory produce 
an article of manufacture including instruction means 
which implement the function specified in the flowchart 
block or blocks. The computer program instructions may 
also be loaded on a computer or other programmable 
data processing apparatus to cause a series of operational 
steps to be performed on the computer or other pro- 
grammable apparatus to produce a computer-imple- 



merited process such that the instructions which execute 
on the computer or other programmable apparatus pro- 
vide steps for implementing the functions specified in the 
flowchart block or blocks. 
[0053] Accordingly, functional blocks of the block diagrams and 
flowchart illustrations support combinations of means for 
performing the specified functions, combinations of steps 
for performing the specified functions, and program in- 
struction means for performing the specified functions. It 
will also be understood that each functional block of the 
block diagrams and flowchart illustrations, and combina- 
tions of functional blocks in the block diagrams and 
flowchart illustrations, can be implemented by either spe- 
cial purpose hardware-based computer systems which 
perform the specified functions or steps, or suitable com- 
binations of special purpose hardware and computer in- 
structions. 

[0054] | n the foregoing specification, the invention has been de- 
scribed with reference to specific embodiments. However, 
it will be appreciated that various modifications and 
changes can be made without departing from the scope of 
the present invention. The specification and figures are to 
be regarded in an illustrative manner, rather than a re- 



strictive one, and all such modifications are intended to 
be included within the scope of present invention. 
[0055] Benefits, other advantages, and solutions to problems 
have been described above with regard to specific em- 
bodiments. No element described herein is required for 
the practice of the invention unless expressly described as 
"essential" or "critical". 



